---
title: "Telemetry Types"
---

import { LanguagesCard } from "/snippets/languages-card.mdx";

Odigos supports the producing and correlation of the following telemetry types:

- Traces
- Metrics
- Logs

For a telemetry type to be collected, a [destination](/backends-overview) that accepts it must be
configured. In addition, users can enable or disable the collection of a
telemetry type on a per-application basis. If none of the applications are
configured to collect a telemetry type, the telemetry type will not be
collected.

## Traces

Distributed traces collected by Odigos will automatically include spans for
popular open source projects such as HTTP clients and servers, gRPC clients and
servers, Database clients, and many more.

In addition, users can enrich their distributed traces with manually created
spans by using the relevant
[OpenTelemetry APIs](https://opentelemetry.io/docs/instrumentation/).

The collection of traces is achieved by combining two open source technologies:

- OpenTelemetry for languages with JIT compilation such as Python, Java,.NET and
  Javascript.
- eBPF for compiled languages such as Go.

Being based on popular open-source standards allows Odigos to automatically
support a huge number of libraries and frameworks. Below is a list of supported
libraries for every language:

<LanguagesCard
  golangUrl="https://github.com/odigos-io/opentelemetry-go-instrumentation/tree/master/pkg/instrumentors/bpf"
  golangDescription="opentelemetry-go-instrumentation/ pkg/ instrumentors/ bpf/"
  javascriptUrl="https://github.com/open-telemetry/opentelemetry-js-contrib/tree/main/plugins/node"
  javascriptDescription="opentelemetry-js-contrib/ plugins/ node/"
  pythonUrl="https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation"
  pythonDescription="opentelemetry-python-contrib/ instrumentation/"
  javaUrl="https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation"
  javaDescription="opentelemetry-java-instrumentation/ instrumentation/"
  dotnetUrl="https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/tree/main/docs/config.md#instrumented-traces-libraries-and-frameworks"
  dotnetDescription="opentelemetry-dotnet-instrumentation/ docs/ config.md"
  phpUrl="https://github.com/open-telemetry/opentelemetry-php-contrib/tree/main/src/Instrumentation"
  phpDescription="opentelemetry-php-contrib/ src/ Instrumentation/"
  rubyUrl="https://github.com/open-telemetry/opentelemetry-ruby-contrib/tree/main/instrumentation"
  rubyDescription="opentelemetry-ruby-contrib/ instrumentation/"
/>

## Metrics

There are three kinds of metrics that Odigos supports:

- Metrics related to the running of the application (number of HTTP requests,
  latency, DB connections, etc.)
- Metrics related to the language runtime (GC, threads, heap, etc.)
- Metrics related to the host environment (CPU, memory, disk, etc.)

### Applicative Metrics

Application-related metrics are derived from the distributed traces described
above. Many observability vendors automatically compute application metrics
according to the distributed traces. For example, the number of requests served
by the application is computed by counting the number of spans with the
`http.server` label. In case a destination that does not automatically compute
application metrics (like Prometheus + Tempo) is configured, Odigos will compute
them on its own by invoking the
[spanmetrics](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/connector/spanmetricsconnector/README.md)
connector.

### Runtime Metrics

Those metrics describe the behavior of the language runtime, such as garbage
collection, threads, heap, etc. Runtime metrics are collected by the same
mechanism that collects distributed traces.

### Host Metrics

Host-related metrics are collected via the
[host metrics receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver)

## Logs

Currently, Odigos will ship logs written by the application to the stdout or
stderr of the process. Correlation to other telemetry types will be done
according to timestamp and resource.

We are in the process of shipping logs using the same mechanism that collects
distributed traces, this would allow users to correlate logs to distributed
traces and metrics in a more accurate way.
